1. Field of Invention
This invention relates generally to software development and more particularly to testing of communication software.
2. Discussion of Related Art
Software is often tested as it is developed or upgraded. In many instances, the software is tested in an environment that is as close as possible to its intended operating environment. To test communication software, such as a network stack in a computer, testing is often performed with a computer executing the software to be tested connected to another computer executing test software.
FIG. 1A illustrates a typical hardware test environment that can be used to test a communication software component. In FIG. 1A, computer 110 is connected to computer 112 through physical connection 114, such as a network cable or wireless link.
During a test of communication software, information is exchanged between computers 110 and 112, resulting in the communication software being exercised. FIG. 1B illustrates a software architecture of the typical test environment of FIG. 1A. Computer 110 contains the communication software to be tested, a network stack 122 in the example of FIG. 1B, and a test application 120 that communicates through network stack 122. Network stack 122 in computer 110 is a portion of the operating system, allowing the test application 120 to be developed like a conventional program that runs on the operating system of computer 110.
Network stack 122 communicates with a hardware driver 124 installed in computer 110. Driver 124 is a software component programmed to operate a network card (not shown). Many variations of network cards exist, each of which may have its own driver. To allow any such hardware card to work in a computer, such as a desktop computer, a standard interface is specified between the network stack and the driver. In computers running the WINDOWS® operating system, the interface standard is referred to as NDIS.
Physical connection 114 is provided from the network card in computer 110 to computer 112. Another network card (not shown) is provided in computer 112 and connected to physical connection 114, allowing information to be transmitted from one computer to another over physical connection 114. For some simple tests, the software configuration of machine 112 is identical to that of machine 110.
In computer 112, a second driver 126 controls the network card. Because network stack 122 is being tested, it is often desirable to bypass the network stack in computer 112. Doing so may make it difficult to identify failures cased by network stack 122. To avoid these concerns, test driver 128 communicates directly with hardware driver 126 via an NDIS interface.
Drivers typically include a standard interface that may be used by a network stack or other software components to communicate with the driver. One standard interface uses IOCTL commands. Test tool 130 communicates with test driver 126 using IOCTL commands.
In an operating computer, direct access to a hardware driver may also be available, effectively bypassing the network stack. For example, FIG. 1B shows a bypass path 130 from the top to the network stack to hardware driver 124. In an application running on computer 110, such a path is used, for example, to connect to a network card that includes hardware to perform some or all of the functions performed by a network stack. When the network stack 122 is called by the application and the bypass is available, the network stack does not do any of the work itself but instead just hands the work to the hardware driver 124. To determine whether network stack 122 operates correctly, its impact on all communications, including those using bypass path 130, should be tested. A full test of network stack 122 typically includes testing interactions between the network stack and the bypass path 130.